@layout("../../system/layout.html", {title: "概念图解"}){
<div class="panel panel-default" style="padding-bottom: 10px;margin-top:10px;">
    <div class="panel-heading">系统概念图</div>
        <h3>&nbsp;&nbsp;&nbsp;概要</h3>
        <div class="row">
                <h3>1. XSS 跨站脚本攻击剖析与防御</h3>
                <img src="${ctxPath}/static/images/XSS.png" width="800px" height="400px"/>
            <div>
                <pre>
该框架的的具体实行过程如下：

(1) 通过代理服务器抓取客户端的HTTP请求。

(2) 对抓取的HTTP请求进行正则匹配，然后获取用户通过GET/POST请求提交的数据。对获取的数据进行解码处理、包括URL解码、HTM实体解码、Based64解码、Unicode解码等。

(3) 对解码的数据放入DFA敏感字符串匹配算法，寻找敏感字符串的个数。如果敏感字符串超过两个则进入步骤4，否则直接让代理服务器转发数据，因为两个敏感字符的数据不可能构成攻击向量。

(4) 对于超过有两个敏感字符的数据进行特征提取，得到该数据相应的特征函数。

(5) 对步骤4提取的特征，送入最大熵分类器。分类器会根据训练的经验，做出相应的判断，然后输出一个是否为XSS攻击向量的概率。

(6) 对得出的概率和操作者设定的阈值做比较，如果低于相应设定的阈值就直接让代理服务器转发数据、否则就判定为XSS攻击然后给出警告。



该检测框架的特点：

(1) 不影响服务器的配置和服务器程序的配合：如果一个检测机制较大的依赖服务器端的配置策略，那么需要开发和维护人员话费较大的精力在服务器的额外开发和维护上，不符合实际使用情况。

(2) 不受各种版本浏览器的解析限制：从第二章XSS攻击检测研究现状看来，很对防御机制建立在特定的浏览器之上，这种策略无法适用广大的用户。

(3) 有较好的检测效果，应对多种XSS攻击向量变种：依赖于静态检测如纯粹的正则匹配无法应对层出不穷的XSS绕过技巧 ，容易漏判和误判。所以需要一个动态灵活的XSS攻击检测机制。


3、详细实现过程的源码如下：<a href="https://download.csdn.net/download/qq_16393511/10931571">XSS检测.源码下载/点击下载</a>



4、测试效果

   搭建了简单的LAMP服务器之后，写了一个检测的测试网页。检测准确率在95%以上。

在输入框里输入相应的跨站脚本之后检测效果如图：
<img src="${ctxPath}/static/images/run1.png" width="500px" height="350px"/>
                </pre>
<br/>
                <h3>2. Cookie，session，Request作用域以及服务器暴露问题</h3>

                <img src="${ctxPath}/static/images/cookie.png" width="600px" height="200px"/>
                <pre>
问题描述：

服务器中的项目在脆弱扫描中会产生项目的path，容易遭受外部攻击，现在需要将cookie中的path属性删除。
 <img src="${ctxPath}/static/images/cookie1.png" width="600px" height="200px"/>

解决办法有两种

（1） 从代码解决，基于web的容器建立webListener，通过设置cookie.setPath(“/”)属性来处理问题，但是这种处理办法治标不治本，当用户第一次访问的时候cookie还是会记录原Path属性，之后的再次访问，属性会被容器置换。

（2） 从容器本身解决这个问题：以Tomcat为例，Tomcat6及以下版本略有不同，现将配置的通用设置配置如下：包含Tomcat的各个版本基本均适用。
在conf 文件夹下找到 context.xml
修改 Context 为：Context sessionCookiePath="/"
找到  server.xml  在  Connector     中加入如下一行：emptySessionPath="true"   这样就可以了
    Connector port="80" protocol="HTTP/1.1"
               connectionTimeout="20000"
               redirectPort="8443"
               emptySessionPath="true"

                </pre>
                <br/>
                <h3>3. 老系统SQL注入攻击以及HTML等常见注入攻击</h3>
                <pre>
（1） 什么是sql注入
    SQL注入指的是发生在Web应用对后台数据库查询语句处理存在的安全漏洞，简单的说，就是在输入字符串中嵌入SQL指令，在设计程序中忽略了对特殊字符串的检查，这些嵌入的指令便会被误认为正常的SQL指令，在数据库中执行，因此可以对后台数据库进行查看等工作，甚至破快后台数据库造成严重后果。
目前SQL注入大致分为普通注入和盲注

    普通注入：根据后台数据库提示有价值的错误信息进行注入
    盲注：有经验的管理员在给出错误页面时，没有提供详细的错误信息。测试者需要运用脚本通过仅有的判断信息(比如时间差)对表中的每一个字段进行探测，从而实现注入的技术。
(盲注的难度较大，但注入测试中经常会遇到)

（2） SQL注入普遍的思路
    1.发现SQL注入位置
    2.判断后台数据库类型
    3.确定XP_CMDSHELL可执行情况
    4.发现WEB虚拟目录
    5.上传ASP脚本
    6.得到管理员权限
    7.SQL注入技术
    8.强制产生错误
    9.采用非主流通道技术
    10.使用特殊的字符
    11.使用条件语句
    12.利用存储过程
    13.避开输入过滤技术
    14.推断技术
    15. ......

（3） 普通注入示例
    以著名的IBM公司所提供的SQL注入测试平台

    我们在这个网站上发现了一个登录的页面，现在我们在表单中的Username中输入“admin'”，Password中输入一样的字段

    点击‘Login’登录按钮后，我们得到了一个报错的页面，根据提示“Syntax error (missing operator) in query expression 'username = 'admin'' AND password = 'admin'''.”我们可以猜测到大概的SQL语句应该是“select * from [users] where username=? and password=?”

    SQL注入其实很简单，别一不留神就被利用了

    我们返回登录页面在Username和Password中输入“admin' or '1”然后再点击登录，我们就能意外的进入到登录页面之后了

    SQL注入其实很简单，别一不留神就被利用了

    是不是还是一脸懵，现在我们来解释一下为什么会这样，之所以能够登陆成功，是因为SQL的语句变成一下的语句：
    select * from [users] where username= 'admin' or '1' and password='admin' or '1'
    根据SQL中逻辑运算的优先级，or低于and，最后的or ‘1’永远成立，所以该条件表达式结果为True，此语句同等于下面的这条语句
    select * from [users]

    SQLmap工具注入示例

    这个页面通过了一次提交之后，我们得到了几个信息，一个是提交的地址，还有就是cookie值，我们通过这几个信息使用sqlmap工具项检测一下有没有sql的注入点

    SQL注入其实很简单，别一不留神就被利用了

    从检测的结果中，我们看到了包含错误的SQL注入点，以及UNION查询注入点，此外，还进一步的探测到了数据库的版本是MySQL5.0的，Web应用平台是PHP5.3.2/Apache2.2.14

    使用SQLmap的“--dbs”选项，就可以根据所识别的不同数据库管理平台类型来探测包含的数据库名称，除了发现MySQL默认的系统数据库information_schema之外，我们还发现了Web应用的数据库dvwa

    使用“-D dvwa --tables”选项指定了数据库，然后获得了此数据库下的所有表，竟然表我们都能看到了，接下来我们来看看表里得到内容吧

    加上“-D dvwa --tables -T users --columns --dump”选项前面的-D选项指定数据库，后面-T指定表，最后我们看到了表中的内容，从中我们看到了一个admin的账户，将password放到在线解密MD5的网站上，我们的到密码就是admin，拿着这个账号密码，轻松的进入到后台中

（4） SQL注入如何防范
    通过一开始的两起案件和后面我所示范的简单注入，相信大家应该知道SQL的注入该有多危险了吧，下面给大家普及几点防范SQL注入的方法：

    输入验证
    检查用户输入的合法性，尽量的限制用户输入特殊的符号，确信输入的内容只包含合法的数据。数据检查应当在客户端和服务器端都执行之所以要执行服务器端验证，是为了弥补客户端验证机制脆弱的安全性。

    错误消息处理
    防范SQL注入，还要避免出现一些详细的错误消息，因为可以利用这些消息。要使用一种标准的输入确认机制来验证所有的输入数据的长度、类型、语句、企业规则等。

    加密处理
    在一开始的CDNS例子中没有加密的数据就直接被利用了，但是加密了就不一定会解密成功，尽量不要用一些常见的加密算法，就算用也要使用32位以上的加密算法，将用户登录名称、密码等数据加密保存。加密用户输入的数据，然后再将它与数据库中保存的数据比较，这相当于对用户输入的数据进行了“消毒”处理，用户输入的数据不再对数据库有任何特殊的意义，从而也就防止了注入SQL命令。

    存储过程来执行所有的查询
    SQL参数的传递方式将防止利用单引号和连字符实施注入。此外，它还使得数据库权限可以限制到只允许特定的存储过程执行，所有的用户输入必须遵从被调用的存储过程的安全上下文，这样就很难再发生注入式了。

    <strong style="color: #00a2d4;">系统在 com.scott.dp.common.xss宝中有常见的几个注入防止，可供参考.</strong>
                </pre>
            </div>
        </div>
</div>
<script type="text/javascript">
    var vm = new Vue({
        el: '#dpLTE',
        data: {
            htmlResult: '',
            textResult: ''
        }
    });
</script>
@}